Hacking my Trash Company
Background:
Trashbilling.com is a site I am required to use to pay my trash bill. When I logged on to pay the first time and noticed there was no password or authentication of any source I was naturally concerned about their security posture and the safety of my payment data. I decided to look around for anything obvious that I could see (without doing anything illegal). Prudance dictated I work anonymously to protect myself from unwarranted reprisal. So everything below was tunneled through Tor and proxychains.
A quick disclaimer: this was not a coordinated penetration test or a bug bounty discovery, rather a “see what is obviously open to me”. This is not even a thorough test, nor was it meant to be. My intent was to show the company that their security posture was outdated, and provide a different perspective to their developers, who could then test the web application themselves.
Responsible disclosures are normally surrounding software applications, however I wanted to ensure the developers patched the site that held my credit card data, so I treated this disclosure in the same way.
The following is the results of my efforts, released in full disclosure following their 90 day remediation period.
Account Num Enumeration/PII Leak:
View Source on trashbilling.com/index.php reveals a client-side validation script at /js/valid_acct_num.js which ensures only valid account numbers are inputted.
This JavaScript file was unobfuscated and even had comments explaining the sections of code. A simple reverse engineering of this script’s algorithm revealed the first 11 digits were the account number and the last digit was a checksum. Using my own acct number as a seed, I incremented the first 11 digits by 1 and calculated a new checksum which I appended as the 12th digit. Entering this new number into the homepage’s “View Your Account” opened the user account information of a random user in my area (someone who used the same trash company, referred to on trashbilling.com as a "hauler").
Uh oh…
In this account summary I could see the account holder’s name, phone number, email, bank name, and the last six digits of their credit card number as well as expiration date.
Scripting a program to generate 100 account numbers, after my initial seeded number, worked as well. I picked a few accounts at random to verify, and all of them opened active user’s accounts, showing billing balances as well as all of their PII. In instances where the user had used their bank account and routing number instead of a CC, I could see the name of their bank as well.
Trashbilling.com actually posts this meme on their trashbilling.com/faq.php. I found it pretty funny, but disagree with the flippant approach to billing applications. The PII that is freely available is valuable, especially when aggregated together. Consider a phishing attempt with some social engineering. A unsuspecting individual is more likely to trust an email when it accurately references their address, full name, bank, CC postfix, etc. Not to mention, password protecting PII is part of PCI-DSS, to which trashbilling.com advertises compliance.
On a lighter note, there’s nothing stopping me from changing their email, filed banking info, and address (I’ll save this one for some petty revenge on my neighbors-
now who’s going to pick up your trash? MUAHAHAHA).
A quick Google search for “https://www.trashbilling.com/index.php?customer_id=” revealed another user's account number which I ran in my script to generate a new block of accounts, this time based out of Vermont. This suggested that each group of accounts native to one hauler (trash company) has a new, non-incremental account number. However, each account native to that hauler increments sequentially. To discover every account "block", without more probing, I would need a sample account under that hauler.
Now that I had access, I was curious what kind of damage could be done (without doing any damage, of course). To this end, I started digging.
Denial of Service:
Trashflow.com allows a password, however it is optional. For users without a password, I could set a password of my choosing, locking them out of their own account in a denial of service, which could be distributed over all accounts. This is a reversable and petty DOS, but could be a way to annoy the help desk or distract them from something more malicious.
Cross Site Scripting (XSS):
Probing around these fields reveals there is a XSS vulnerability in the email field, but the PHPSESSID cookie doesn’t reveal anything I don’t already know.
*******@gmail.com<script>alert(document.cookie);</script>
I'd rank this as pretty trivial, but it's a "vulnerability" nevertheless.
SQL Injection (SQLI):
Then I found something good.
I was suspicious that there would be SQL issues given the security posture of the rest of the site and, lo and behold, messing with the credit card update functions revealed a SQL Injection vulnerability in the credit card number field. Putting a single quote here broke the web application and spits out a significant amount of debug information. The risk here is, hopefully, obvious: an attacker could do all sorts of damage with injection in the payment database. Without authorization for a full pentest, I stopped probing here, which took every ounce of my self control.
Trashflow 3.0.0
I was walking a fine line, legally, so I quit messing with the live website and documented my work to send to Ivy Computers. I hoped that I could convince them, at the very least, to require password protection on all accounts (since my data was as vulnerable as anyone elses). However, curiosity got the better of me and I wanted to see how the Trash Hauler interacted with the trashflow servers, wondering if I could find more of those account number “blocks”.
Trashbilling.com lists trashflow.com as the parent software, so I did some recon. Trashflow.com distributes trashflow v 3.0.0, the software that connects haulers to trashbilling.com. The software costs $2500 for a license, however they have a demo version available for 90-day trial, which I downloaded and installed in a VM. Under "billing" (F2) there is a button for Trash Billing which opens a pop up that lists “Send Info to the Web” as an option. This button connects to an ftp server so I ran wireshark to sniff this traffic. Wireshark revealed an ftp handshake with ftp.ivycomputer.com including the ftp username and password.
I connected to ftp.ivycomputer.com using the username and password to look around. At no point did a banner announce that Unauthorized Access was prohibited. In fact, there was nothing at all to suggest this was sensitive information. Inside was one large directory listing numerous .zi files with names like F402290005969.zi.
The file trashflow pulled from the FTP server, F402290005969.zi, was a corrupted zip file, however xxd and hexdump revealed the file contained payment history data for users in my demo software. That means that the other files in the FTP folder had payment history for actual users sitting up for grabs. Potentially, this information could also be manipulated, as the FTP allowed PUT requests as well as GET.
Each of the file names in the FTP server appeared to be account numbers, so I tried a few on trashbilling.com like before and they each worked, this time logging me in to an account with a
unique hauler, again showing me all the User PII. Bingo. This could be used to find EVERY trashbilling.com account by using each of the file names as a seeded account and brute forcing the block of accounts under that hauler.
At this point I'd found a way to enumerate every user's PII (those who hadn't used a password) and a way to
possibly steal their CC information (via SQLI). This should be substantial enough for Ivy Computers to take seriously, but in the interest of curiosity I wanted to see what else Trashflow 3.0.0 would reveal.
The software has several other functions that connect to the ivycomputer.com servers, pressing “System” (F10) and selecting “Maintenance” then “Send Backup to TrashFlow” (There has to be a backup already created) while sniffing with Wireshark revealed a second set of credentials to ftp.trashflow.com
Logging in to ftp.ivycomputer.com with these new credentials reveals another of files on ivycomputer’s servers, this time with backups saved. An attacker could probably trojanize a backup here that, when downloaded again, executes on the requester (the hauler’s) systems, creating the potential for further exploitation of the individual hauler’s networks. Of course, there was no way I could attempt this outside a proper pentest, so it’s a theoretical attack vector only.
Hardcoded Passwords:
Installing Trash Flow 3.0.0 builds several helper .exe binaries in the installation folder. Analyzing the assembly of cash_drawer_cc.exe with Immunity Debugger reveals a very simple, 5 character password. Trying this default password in trashflow.exe works in “System”->”Communication Control Setup”, where I could see
all passwords to further program functionality, including the ablility to edit user’s payment data from the hauler’s end.
License Bypass:
Trashflow 3.0.0 has a license update feature at “System”->”Update”->”License Update”.
To bypass the license check, I changed the JNZ (jump if not zero) and JMP (unconditional jump) below to JMP and JNZ, respectively, which forces the program to jump unconditionally to the license accept subroutine (and skip the license deny one), accepting the fake license. There are numerous ways to bypass this check, I imagine, but I wanted a quick way to access the “privileged” software functionality.
Once the license is applied, more was available to me- notably “Get Web Payments” under billing trash payments. Sniffing that traffic reveals the below:
This doesn’t appear to have a ftp transfer like before, presumably its pulling actual CC data. However, we can see the payment data is stored on eft2.trashbilling.com port 8244. I can’t say if there were any vulnerabilities over this socket without further testing, but it is valuable information nonetheless.
Public Exploits:
Last but not least, each of these FTP sites (ftp.ivycomputer.com and trashflow.com) run their FTP servers off of vsFTPd 2.0.5, which is outdated and riddled with DOS exploits on Exploit-DB.
Conclusion:
All the above was compiled and sent off to Ivy Computers, who responded immediately. They did not have any formal bug reporting program, but were grateful for the report nonetheless. After their analysis, the CEO contacted me with an offer of a $500 bounty/award for my work which was unexpected but welcome.
My thanks to Ivy Computers for the open communications and their willingness to remedy the issues identified. Most of these vulnerabilities have been patched by now, with plans in place for further improvement of trashbilling.com
